One or more aspects relate, in general, to servers, and in particular to facilitating a health check of a newly installed server, such as a transaction server.
Nowadays, many servers accessible over networks, such as the Internet, mobile communication networks, and so on, offer services, which may be hosted by the server or for which the server acts as an intermediary. Often, such services are of a time-critical nature or at least are expected to be delivered within a certain amount of time, which therefore requires the server to maintain certain performance levels in order to meet performance expectations.
Such servers are commonly referred to as transaction servers. A transaction server manages business transactions over a computer communications network. The transaction server for example may act as an intermediary between a device requesting a particular service and a device providing the requested service. The transaction server can be described to act as glue, holding essential data processing activities together. Further, a transaction server allows an enormous volume of information to remain accurate and ensures transactions are completed without interruption or data corruption. To achieve the foregoing, generally a transaction server provides for “roll back” capability through the implementation of the “ACID” set of properties—namely atomicity, consistency, isolation and durability. Thus, the transaction server is responsible for maintaining high performance, availability and data integrity and ensures that no computer has too much or too little to do.
A server, such as a transaction server, can be a software application executing in memory of a computer forming a composite device, or can be a software application executing in memory of a computer also hosting the execution of other applications, whether in the same process address space or in a separate process address space, such as in a separate virtual machine. An example of a transaction server is IBM CICS online transaction processing application. CICS along with the COBOL programming language has provided the backbone of enterprise mainframe computing for several decades and more recently has been supported in the mid-range and network personal computing environments.
A server, such as a transaction server, is to maintain a desired service level, e.g. a level of service as specified in a service level agreement (SLA), such that transaction services involving the transaction server are sufficiently available and are handled sufficiently quickly. In other words, the transaction server is not to be overloaded or otherwise stressed, i.e. is healthy and stable. In a transaction server environment, the health and stability of the transaction server can be measured according to many different measurable metrics.
Traditionally, metrics were evaluated after degradation of the performance of a transaction server, for example by evaluation of log messages in which abnormal events or conditions have been reported or by using independent monitoring logic to monitor system resources in order to generate an alert or to log a message when a threshold has been exceeded in any given resource, including memory or processor usage. Such performance metrics furthermore could be captured during the operation of the transaction server and analyzed at a later time to retro-reflectively identify poor health of the transaction server. Hence, such traditional approaches were based on detecting poor health of the transaction server, which often meant the consequential performance degradation of the service or transaction handled by the transaction server, which was undesirable.
More recently, predictive methods for predicting transaction server performance failure have been introduced. Such methods rely on comparing a monitored performance metric of the transaction server to a benchmark of performance metrics, which comparison can trigger an alert or a corrective action upon the monitored performance metric falling outside a threshold variance from the benchmark, thus potentially avoiding unwanted performance degradation. Such methods are particularly suitable for transaction servers having well-established benchmarks. However, when creating a new instance of a transaction server, it may be difficult to determine when the new transaction server operates in a healthy manner without avoiding deterioration of the transaction server performance.